1. Field of the Invention
The present invention relates to a method and apparatus for use in a communications network, for example a Universal Mobile Telecommunications System having an IP Multimedia Subsystem.
2. Description of the Related Art
IP Multimedia services provide a dynamic combination of voice, video, messaging, data, etc. within the same session. By growing the number of basic applications and the media which it is possible to combine, the number of services offered to the end users will grow, and the inter-personal communication experience will be enriched. This will lead to a new generation of personalised, rich multimedia communication services, including so-called “combinational IP Multimedia” services.
By way of background, UMTS (Universal Mobile Telecommunications System) is a third generation wireless system designed to provide higher data rates and enhanced services to subscribers. UMTS is a successor to the Global System for Mobile Communications (GSM), with an important evolutionary step between GSM and UMTS being the General Packet Radio Service (GPRS). GPRS introduces packet switching into the GSM core network and allows direct access to packet data networks (PDNs). This enables high-data rate packets switch transmissions well beyond the 64 kbps limit of ISDN through the GSM call network, which is a necessity for UMTS data transmission rates of up to 2 Mbps. UMTS is standardised by the 3rd Generation Partnership Project (3GPP) which is a conglomeration of regional standards bodies such as the European Telecommunication Standards Institute (ETSI), the Association of Radio Industry Businesses (ARIB) and others. See 3GPP TS 23.002 for more details. The standardisation of UMTS has progressed in phases. The first phase was known as Release '99. The Release '99 specifications define the basic architecture that consists of the UMTS Terrestrial Radio Access Network (UTRAN), Circuit Switched Core Network (CS-CN) and Packet Switched Core Network (PS-CN). The release '99 specification offers traditional circuit as well as packet-switched services. The next phase in the standardisation process was Release 4, adding new services to the '99 architecture. Release 5 represented a significant shift, offering both traditional telephony as well as packet-switched services over a single converged packet-based network.
The UMTS Release 5 architecture added a new subsystem known as the IP Multimedia Subsystem (IMS) to the PS-CN for supporting traditional telephony as well as new multimedia services. IMS provides IP Multimedia services over mobile communication networks (3GPP TS 22.228, TS 23.228, TS 24.229, TS 29.228, TS 29.229, TS 29.328 and TS 29.329 Releases 5 to 7). IMS provides key features to enrich the end-user person-to-person communication experience through the use of standardised IMS Service Enablers, which facilitate new rich person-to-person (client-to-client) communication services as well as person-to-content (client-to-server) services over IP-based networks. The IMS is able to connect to both PSTN/ISDN (Public Switched Telephone Network/Integrated Services Digital Network) as well as the Internet. The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (or user terminals and application servers). The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to-user protocol, IMS allows operators and service providers to control user access to services and to charge users accordingly. The 3GPP has chosen SIP for signalling between a User Equipment (UE) and the IMS as well as between the components within the IMS.
FIG. 1 is an illustrative diagram showing a UMTS communications network 200 comprising a User Equipment (UE) 204 located within a Visited Network 202. The UE 204 is attached to a Serving GPRS Support Node (SGSN) 208 via a UTRAN 206, which is in turn in communication with a Gateway GPRS Support Node (GGSN) 210. Within the Visited Network 202, the GGSN 210 communicates with a Proxy Call Session Control Function (P-CSCF) 212, which is the first point of contact in the visited IMS network for the UE 204. The P-CSCF 212 forwards SIP registration messages and session establishment messages to the Home Network 214.
The first point of contact within the Home Network 214 is the Interrogating Call Session Control Function (I-CSCF) 216, which is an optional node in the IMS architecture, whose main purpose is to query the Home Subscriber Server (HSS) 220 to find the location of the Serving Call Session Control Function (S-CSCF) 218. The S-CSCF 218 performs session management for the IMS network, and there can be several S-CSCFs in the network. The HSS 220 is a centralised subscriber database, and has evolved from the Home Location Register (HLR) from earlier UMTS releases. The HSS 220 interfaces with the I-CSCF and the S-CSCF to provide information about the location of the subscriber and the subscriber's subscription information.
The communications network 200 further comprises an application server 222, a database 224 and a mail server 226 located in the Home Network 214. From the S-CSCF 218, signalling messages are passed to the intended destination, which may be another Release 5 IMS network 228 comprising a UE 230, or to a legacy network 232 comprising a PSTN interfaced through a Media Gateway Control Function (MGCF), or to an IP network 234.
Specific details of the operation of the UMTS communications network 200 and of the various components within such a network can be found from the Technical Specifications for UMTS which are available from http://www.3gpp.org.
Further details of the use of SIP within UMTS can be found from the 3GPP Technical Specification TS 24.228 V5.8.0 (2004 March), but a summary will now be provided with reference to FIG. 2, which illustrates schematically how the IMS fits into the mobile network architecture in the case of a GPRS/PS access network (IMS can of course operate over other access networks). Call/Session Control Functions (CSCFs) operate as SIP proxies within the IMS. As mentioned above, the 3GPP architecture defines three types of CSCFs: the Proxy CSCF (P-CSCF) which is the first point of contact within the IMS for a SIP terminal; the Serving CSCF (S-CSCF) which provides services to the user that the user is subscribed to; and the Interrogating CSCF (I-CSCF) whose role is to identify the correct S-CSCF and to forward to that S-CSCF a request received from a SIP terminal via a P-CSCF.
A user registers with the IMS using the specified SIP REGISTER method. This is a mechanism for attaching to the IMS and announcing to the IMS the address at which a SIP user identity can be reached. In 3GPP, when a SIP terminal performs a registration, the IMS authenticates the user, and allocates a S-CSCF to that user from the set of available S-CSCFs. Whilst the criteria for allocating S-CSCFs is not specified by 3GPP, these may include load sharing and service requirements. It is noted that the allocation of an S-CSCF is key to controlling (and charging for) user access to IMS-based services. Operators may provide a mechanism for preventing direct user-to-user SIP sessions which would otherwise bypass the S-CSCF.
During the registration process, it is the responsibility of the I-CSCF to select an S-CSCF if a S-CSCF is not already selected. The I-CSCF receives the required S-CSCF capabilities from the home network's Home Subscriber Server (HSS), and selects an appropriate S-CSCF based on the received capabilities. [It is noted that S-CSCF allocation is also carried out for a user by the I-CSCF in the case where the user is called by another party, and the user is not currently allocated an S-CSCF.] When a registered user subsequently sends a session request to the IMS, the P-CSCF is able to forward the request to the selected S-CSCF based on information received from the S-CSCF during the registration process.
Within the IMS service network, the Application Servers (ASs) are for implementing IMS service functionality. Application Servers provide services to end-users in an IMS system, and may be connected either as end-points over the 3GPP defined Mr interface, or “linked in” by an S-CSCF over the 3GPP defined ISC interface. In the latter case, Initial Filter Criteria (IFC) are used by an S-CSCF to determine which Applications Servers should be “linked in” during a SIP Session establishment (or indeed for the purpose of any SIP method, session or non-session related). The IFCs are received by the S-CSCF from an HSS during the IMS registration procedure as part of a user's User Profile.
An important function of any mobile core network is the enforcement of service level policies. These policies dictate, inter alia, what particular users may and may not do, and what they will be charged. Another policy might dictate the Quality of Service (QoS) that particular users will receive. Service level policies, which might be thought of as general policy statements, are enforced using detailed policy “rules”. A single policy may require a set of policy rules. Each policy rule will comprise a first subject part identifying the packets that the policy rule will be applied to, and a second action part. The subject part may in some cases be a packet filter. Policy rules are installed into a node through which all traffic of the users pass or into multiple nodes, which collectively handle all traffic of the user.
In the case of 3GPP, it is envisaged that policing and charging functionality will be controlled from a so-called Policy and Charging Rules Function (PCRF) logical node, based on signalling from Application Functions (AFs) providing high level services to users. Consider for example the IP Multimedia Subsystem (IMS) described above. When a call is set up over the IMS, the IMS Proxy Call/State Control Function (P-CSCF) acts as AF from a policy and charging point of view and informs the PCRF of the new session. In particular, the P-CSCF sends to the PCRF a descriptor of the IP flow, and an abstract definition of the QoS to apply. The PCRF has installed into it, for each user, a policy which describes how packet flows for that user are to be handled, i.e. allowed/denied services, charges, actual QoS, etc. (This may be installed manually into the PCRF or may be installed remotely, e.g. by a user's home network where the PCRF is located in a “visited” network.)
Considering this scenario in more detail, the AF sends to the PCRF a flow descriptor in the form of a complete or partial five-tuple vector containing: (1) IP source address, (2) IP destination address, (3) an identification of the used transport protocol (e.g., TCP or UDP), (4) source port number and (5) destination port number. The PCRF applies the policy to this vector to generate a set of policy rules. For example, the policy may specify the charge and QoS to be applied to a call between the IP addresses and port numbers contained in the vector. The resulting rules will contain the five tuple vector as the subject part and the appropriate charging and QoS actions in the action part. The PCRF installs the policy rules into the traffic node at which the rules will be enforced. If the addresses/port numbers of a packet passing through the enforcement node match the filter part of a rule, the action specified at that rule is carried out. The traffic node is referred to as the Policy Enforcement Function (PEF) and, in the case of a cellular network incorporating GPRS, is usually located in a GPRS Gateway Support Node (GGSN), or an evolution of the GGSN.
Flexible Bearer Charging (FBC) and Service Based Local Policy are two policy control architectures defined in 3GPP Rel-6 (TS 23.125 and TS 23.207 respectively). The two architectures are being harmonised for 3GPP Rel-7 into one Policy and Charging Control (PCC) architecture, in line with the evolution direction set out in TR 23.803. The policy functionality is distributed in the network across a number of entities: the Application Function (AF), the Policy Control and Charging Rules Function (PCRF), and the Gateway (GW), as shown in FIG. 3 of the accompanying drawings (from TR 23.803).
For Rel-6 policy control over Go the binding mechanism uses an Authorization Token and one or more Flow Identifiers. An important role for the token is to provide address information to the GGSN (GW) for finding the Policy Decision Function (PDF) that issued the token, thus being the node to contact for seeking authorization for the flows described by the Flow Identifiers. The Rel-6 Flow Based Charging architecture ensures that both the Traffic Plane Function (TPF) (in the GW) and an AF, which requires information being provided to the Charging Rules Function (CRF) for the user session, contacts the same CRF. For Flow Based Charging, the TPF contacts the CRF based on access point the UE connects to (i.e. Access Point Name, APN) and the AF contacts the CRF based on the end user (IP) address as experienced at the AF.
The Rel-7 PCC will re-use the Rel-6 FBC TPF to CRF addressing mechanism of Flow Based Charging for the GW to PCRF addressing. As the Flow Based Charging solves the problem of the AF finding the same CRF that the TPF contacts, the Rel-7 AF will re-use the Rel-6 AF to CRF addressing mechanism of Flow Based Charging for the AF to PCRF addressing. It is therefore the GW that will select the PCRF to be serving the UE, and the AF will ensure that it provides its authorisations to the same serving PCRF.